Bug Proofing Visual Basic: A Guide to Error Handling and Prevention
(Publisher: John Wiley & Sons, Inc.)
Author(s): Rod Stephens
ISBN: 0471323519
Publication Date: 11/01/98

Instead of hiding the bug, the function should draw attention to it. It should explicitly check its arguments to verify that they make sense. If not, the routine should make the bug obvious by stopping or by raising an exception.

For example, in Visual Basic 5 and 6, the program can use the Debug.Assert statement to verify that the argument is at least 0. Debug.Assert takes a Boolean expression as an argument. If the expression is false, Visual Basic halts execution at the Assert statement. The developer can then examine the code to find the problem.

When it compiles the application, Visual Basic removes the Debug.Assert statement from the code. If the compiled program encounters this bug, it cannot stop because the Debug.Assert statement is missing. To allow the program to continue if an unexpected error occurs and the Debug.Assert statement has been removed by the compiler, the code can use defensive programming techniques.

Public Function Factorial(num As Integer)
     ‘ Validate parameters.
     Debug.Assert num >= 0

    If num <= 0 Then
        Factorial = 1
    Else
        Factorial = num * Factorial(num - 1)
    End If
End Function

Take the offensive and catch bugs before they catch you. Chapter 5, “Exposing Bugs,” has a lot more to say about writing code that makes bugs obvious instead of hiding them.

Write for Others

Program as if someone else is going to read your code later; someone almost certainly will. Even when you read the code later, it may be far enough in the future that you may as well be someone else. By the time you read the code again, you may not remember any of the routine’s finer details.

Assume the person reading your code is not the brightest programmer in the world and will misunderstand the code if possible. In many companies, maintenance programmers are often the least experienced so this may be close to the truth.

On the other hand, this person is a programmer and has at least some programming knowledge, so you do not need to explain every little detail about how Visual Basic works. You need to explain what the code is trying to do, not what the ReDim statement does.

The person may be trying to understand your code, or he may be trying to find a bug. The bug may be in your routine, or it may be in another routine that calls yours. To make it easy for this person to understand what your code is doing, keep the code as straightforward as possible. Remember that this later person may be you—the time you save may be your own.

Write for Humans

Computers execute programs but you need to write code for people. The computer does not care whether the code contains comments, proper indentation, and variables with meaningful names. It does not care if the code is written in Visual Basic, Delphi, or machine code. In fact, it does not care if the code does what it is supposed to do. The computer will not locate and fix bugs. It will not even notice a bug unless the program tries to do something illegal like divide by 0.

Only a programmer can examine the code and decide whether it is operating correctly. Only a human can find and correct a bug. Always remember that you write code for other people, not for the computer.

Code for the Ages

Do not use quick and sloppy techniques, expecting to clean the code up later. Chances are good that no one will have time. Assume your code will remain in use exactly as you write it for the next 30 years. Later, if you do have the free time, you can consider rewriting it. Of course, that may introduce new bugs. It is better to get the code right the first time and not rewrite it.

Do not expect to fix code in a future release. That may happen and it may not. There are probably trillions of lines of code still in use that were written 10, 20, or even 30 years ago. The programmers who wrote that code probably thought it would be rewritten a few years later. Had they been correct, there would never have been a year 2000 problem.

I once worked with a huge mainframe application that included code written over a span of more than 20 years. I am certain the programmers who started the project had no idea it would still be running decades after they finished the initial release. Over the years, the program had become a conglomeration of code written in several different programming languages. It included data that was compiled into the code. This is the equivalent of putting assignment statements directly into a Visual Basic program instead of loading the data from a database. Whenever the business rules changed, the program had to be recompiled. The company grew to depend on the program until it was absolutely essential to operations. The program cost more than $100 million per year to run, but it could not be rewritten because, after decades of uncoordinated changes, the code had grown too incoherent for anyone to understand.

Write as if your code will be used for many years to come. Chances are good it will be.

Code without Ego

Many programmers become emotionally attached to their code. That is only natural. If you spend a lot of time and effort building something, it is natural that you will become attached to it.

Unfortunately, code sometimes needs to be rewritten. It may need to be rebuilt to implement a better algorithm. After too many bugs have been found in one routine, it may be better to rewrite it from scratch rather than patch it further. Sometimes it may be completely thrown away and replaced with a different method.

You must be ready to let go of your code so it can be rewritten, replaced, or discarded.

Do not feel your code is a reflection of yourself. A bug in your code does not mean you are any less of a person. If you feel that a bug is a stain on your reputation, you will not look as hard as you should for bugs because you will not really want to find any. You will also not be receptive to others testing your code and reporting or fixing bugs.

Many programmers learn these lessons only after years of experience. Some developers never learn. They remain hostile to changes in their code no matter how obvious it is that the changes are improvements.

Remember that the goal is to build the best solution possible, not to stick with the original code until it is an incoherent mass of bug fixes and patches. Do not let ego and attachment stand in the way of improving the code.

Figure 1.3  Program Bad1 displaying the average of a list of random numbers.